In computer programming, an interpreted language is often defined as a programming language whose programs may be executed from source or an intermediate form by an interpreter. Any language may be compiled or interpreted, so this designation refers to a language's implementation rather than syntax. Some languages have both compilers and interpreters, including Lisp, BASIC, and Python. In the past, interpreted languages were compiled line-by-line. In other words, each line was compiled as it was about to be executed, but this has become less common. Most interpreted languages use an intermediate representation, which combines both compilation and interpretation. In this case, a source compiler may output some form of intermediate code representing the executable code for a virtual machine, which is then executed by an interpreter or a software virtual machine. Examples of current common interpreted languages include Java, Visual Basic, Perl, etc.
Java is one of the more popular interpreted programming languages currently being used. A Java software program is usually compiled into an intermediate representation called bytecodes which are then put in ‘class’ files. A software virtual machine called a Java Virtual Machine (JVM) is provided for most platforms and that makes Java programs platform independent and even more popular. As a result, there is a demand for quality Java software and various tools exist to aid programmers in reducing the number of bugs found in released software. Java applications are used to deploy a large number of mission-critical applications on centralized servers, especially in multi-tier environments.
Reliable code coverage tools play a strong role in assessing the quality and performance of software applications and are often credited with reducing the number of bugs found in software released from a software development organization. However, code coverage tools for interpreted languages are few and far between even though the dynamic run-time aspects of interpreted languages provide some interesting opportunities that static compilation environments do not provide.
One of the problems with developing large complex programs in an interpreted language (such as Java) is that most of the time the software developers rely on black-box testing of the integrated application in a mock environment. It is important to test every line of code before the application is deployed in a mission-critical environment. As a result, this line testing is usually achieved through instrumentation logging that is added by the programmers. However, it is not practical to log all code sequences and there are certain code segments or pieces which may not get tested. This can be a problem in long-running mission-critical applications where a glitch can bring down the entire software system. Good code coverage tools are needed are valuable in testing the code of an interpreted application before the application is deployed.
There is another reason more effective code instrumentation tools are needed for interpreted languages. Interpreted languages are sometimes developed to enable a “write-once run-anywhere” strategy, which provides a software vendor's customers with a wide variety of choices for deployment platforms. Good code coverage tools that are available for multiple environments provide platforms which have higher performance and good deployment tools to enable the customers' mission critical needs. Coverage tools are more valuable when the tools are more comprehensive.
Instrumentation solutions have generally used programmers to add kludgy instrumentation using print statements to measure coverage or tools which work on the class files by instrumenting the source code to generate data before the source code is compiled. This method is inspired by the C/C++ style static programming world. Such instrumentation can drastically reduce the performance of an executing program and thereby change the application profile in multi-tier distributed systems.